Hardware advances have enabled many high update rate transaction applications to execute completely in-memory. Such applications include event processing systems, electronic trading systems, multiplayer games, service control applications in telecom, measurement systems, scientific simulations and many others.
The durability of update transactions in these applications is typically provided by a periodic checkpointing process that flushes a consistent memory state to a persistent storage, and a logical redo log that records all the modification requests between consecutive checkpoints. In case of a system failure, a restore process uses the latest persistent checkpoint to initialize the memory state, and a replay procedure, to replay the redo log to re-create the application state at the point before the time of the failure.
In such high update rate systems, checkpoint efficiency and the lack of obstruction to the application operation are crucial. The checkpointing process may be very low-overhead and highly efficient in order not to hinder the high update rates, and to enable frequent checkpointing. Frequent checkpointing, in turn, reduces the redo log size and its associated log replay duration at restore-time. Because checkpoints are run repeatedly, an incremental checkpointing method, whereby only objects changed since the previous checkpoint are detected and persisted, is highly valued.
Approaches to checkpointing may utilize specific methods of taking snapshot of various granularities and therefore the logic of checkpoint management is tightly coupled with the logic of taking the snapshot.
For example, the Copy-On-Update method groups application objects into blocks and copies each block to the shadow state each time an object is mutated during the time interval. Since the update threads are concurrently updating the application state, the update thread needs to acquire locks on the blocks it references. By varying the memory block size, Copy-on-Update tradeoffs between copying and locking overhead. The Copy-on-Update method incurs large overhead and spiky latencies making it unsuitable for high-rate updates. Moreover, it involves quiescing the updates for resetting the update marks and recycling the memories of the shadow objects on the outset of a new checkpointing.
The Wait-Free ZigZag method pre-allocates duplicate space for each tuple, and marks which of the copies holds the snapshot of the tuple. Before the start of a new checkpoint, the application needs to quiesce its updates in order to consistently mark one of the copies of each tuple to serve as the next snapshot tuple.
Another popular technique is Bulk-Copy whereby the whole application state is copied for the checkpointing. Bulk-Copy updates incur high latencies, and it is not applicable for some applications, where, for instance, a complex object structure requires ‘deep copying’.
Experiments have shown that none of the known snapshotting methods is suitable to sustain the whole dynamic range of update rates. All of the above-mentioned methods are intertwined with the specific snapshot taking method, thereby featuring high complexity. With that complexity, the definition and efficient computation of change sets may be prohibitive. Furthermore, some approaches typically result in the enforcement of either application-specific locking or the quiescence of the updates.